REMARKS 

Claims 1-16, 28-49 and 53 were presented for examination and were pending in 
this application. The Examiner rejected claims 1-16, 28-33, 35-44, 49 and 53 under 35 
U.S.C. § 102(e) as being anticipated by U.S. Patent No. 6,389,127 to Vardi et al. 
("Vardi") 1 ; rejected claim 34 under 35 U.S.C. § 103(a) as being unpatentable over Vardi; 
and rejected claims 45-48 under 35 U.S.C. § 103(a) as being unpatentable over Vardi in 
view of the cited MicroSoft NetMeeting document. 

Applicant herein amends claims 1, 9, 28, 32, and 53 and adds new claims 54-69. 

The Examiner rejected claims 1-16, 28-33, 35-44, 49 and 53 under 35 U.S.C. 
§ 102(e) as being anticipated by U.S. Patent No. 6,389,127 to Vardi. Applicant disagrees 
with this rejection. 

Claim 1 and Dependent Claims 
Claim 1 as amended recites: 

1. A computer-implemented method for the intermediation of real time meetings, 
comprising: 

receiving an indication by a requester system that a requester wants to 
request a realtime meeting with a target; 

sending to the target a request to conduct a real time meeting; 

after sending the request, sending by the requester system an 
availability status of the requester; 

queuing the request by the requester system; and 

connecting the requester and the target when the requester and the 

target are mutually available. 

1 The Examiner's statement on page 3, paragraph 2, of the Office Action that claims 17-27, 49, and 53 are 
rejected is assumed to be a typographical error since some of these claims are not pending. 
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In the method of claim 1, after sending a request to the target, the requester also 

sends a status of the requester to the target. Thus,.a requester Alice might send a request 
for a meeting to a target Bob. Even though Alice has requested a meeting, Alice may not 
actually be available at the time she sends the request. Sending the request does not 
indicate Alice's availability. Next, Alice may next send an availability status, e.g., 
available or not-available. Mere sending of a request for a meeting does not signify 
Alice's availability status in the method of claim 1 . She must send her availability status 
separately if she wishes Bob to know it. 

The sections of Vardi noted by the Examiner fail to disclose at least sending by 
the requester system an availability status of the requester (after sending the meeting 
request). Col. 2, lines 65-67; Col. 3, lines 1-9; 15-28, and 40-45, and Col. 8, lines 1-6 of 
Vardi state that the requesting terminal has a "telephone line status" and that sought user 
initiates the call once the seeking user telephone line status "has been determined." No 
mention is made of how such a status is determined. This portion of Vardi is clearly 
discussing determination of physical line availability since it mentions callback in each 
section cited by the Examiner and refers not just to a "status" but to a "line status." It 
does not disclose or suggest that the line status is sent by the seeking user to the sought 
user. Indeed, it is more probable that the sought user requests a status when dealing with 
line availability, since the sought user will place a call if the line is available. Moreover, 
Vardi's disclosure of "telephone line status" is not the same as the "availability status of 
the requester" of claim 1 . 

The Examiner additionally points to Col. 7, lines 25-30 and 49-67 of Vardi. 
Applicant does not find language in these sections stating that a requesting system sends 
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a request for a meeting and then, additionally, sends an availability status of the 
requester. At best, the cited sections disclose that various types of status information can 
be supplied in response to a status request from the seeking user in Vardi. For example, 
the seeking user can request a status of a monitor. Vardi also indicates that the requested 
status can be a logical status of a user (Col. 7, lines 29-30). It is clear, however, that this 
is a logical status entered by a sought user such as user 12 of Fig. 1. See Vardi, Col. 6, 
lines 26-32. 

Dependent claims 2-8 depend from claim 1 and are patentable for at least the 
same reason as claim 1. 

Moreover, new dependent claim 54 recites that the availability status sent to 
the target system is displayed on the target system, along with an indication that the 
requester has requested a meeting. An example of such an embodiment of the present 
invention is shown, for example, in Applicant's Fig. 9(e). In this Figure, a left-most 
column shows an availability status of a calling user. As recited in new claim 55, this 
availability status can be in, out, or unknown. 

New claims 56 and 57 recite similar language for the requester system. 

Claims 9, 28, 32, and 53 

Each of independent claims 9, 28, 32, and 53, as amended, recites language 
relating to sending of an availability status of a requester by a requester system (or 
receiving of such an availability status by a target). These claims and their dependent 
claims 10-16, 29-31, and 33-49 are patentable for at least the same reasons as discussed 
above in conjunction with claim 1 . 
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Claim 34 

The Examiner rejected claim 34 under 35 U.S.C. § 103(a) as being unpatentable 
over Vardi. As discussed above, claim 34 is patentable for at least the same reasons as 
claim 32, from which it depends. The Examiner contends that it would have been 
obvious to a person of ordinary skill in the art to modify Vardi to remove meetings from 
a queue. If the Examiner is relying on personal knowledge as a basis for the motivation 
of one of ordinary skill in the art at the time the invention was made, the Examiner is 
respectfully requested to submit an affidavit to support this personal knowledge. 

Claims 45-48 

The Examiner rejected claims 45-48 under 35 U.S.C. §103(a) as being 
unpatentable over Vardi in view of the cited MicroSoft NetMeeting document. As 
discussed above, claims 45-48 are patentable at least for the same reasons as claim 32. 

The Examiner acknowledges that Vardi does not disclose at least text chat, an 
online collaboration tool, or a shared application. Applicant does not believe that the 
cited art contains motivation for the Examiner's suggested combination. The Examiner's 
only stated motivation for the combination is based entirely on hindsight: "incorporation 
of these old and well-known capabilities would have increased the usefulness of the 
product to potential buyers." Applicant respectfully requests that the Examiner provide a 
location in the cited documents that provide motivation for the suggested combination. 
Merely stating a conclusion that the suggested combination would have improved the 
product does not provide sufficient motivation. Moreover, Applicant does not concur 
that the suggested combination could have been made or that it would have yielded 
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applicant's claimed invention, as few details have been offered as to exactly how such a 



combination would function. 
Additional new claims 

Claim 58 and it dependent claims relate to a user interface such as that shown in 
Figs 9(e) and 9(f). 

Claim 64 and its dependent claims relate to a user interface such as that shown in 
Figs. 9(e) and 9(f). 



In sum, Applicant respectfully submits that the pending claims, as presented 
herein, are patentably distinguishable over the cited reference (including references cited, 
but not applied). Therefore, Applicant requests reconsideration and allowance of these 
claims. 

In addition, Applicant respectfully invites Examiner to contact Applicant's 
representative at the number provided below if Examiner believes it will help expedite 
furtherance of this application. 



Conclusion 



Respectfully submitted, 
BRADLEY S. TEMPLETON 



Date: 
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